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AADH AAR 


2 Introduction 


This Authentication User Agency (AUA) handbook is the administrative handbook which should be referenced for 
integrating with UIDAI as an Authentication User Agency (AUA) to consume or offer authentication services for 
resident service delivery. The purpose of this document is to outline the UIDAI and AUA Engagement process, the 
technical design of AUA Applications and network, and provide information on how to Leverage Aadhaar based 
authentication system in various service delivery applications. 

This document is not intended to address specific low level details of the actual engagement and implementation of 
AUA applications due to the wide range of domain specific applications. This document will help AUAs in Aadhaar 
Authentication based solution implementation and ensuring necessary business and technical compliance. 

The intended audiences for this document are AUAs stakeholders (Business and Technology Teams), the project 
development teams and technical architects. For the technology part, the reader is assumed to have knowledge in 
network administration, web services development and deployment, system security and architecture with good 
level of experience in software development. 

General good practices like project management, resource engagement, general security, hardware setup etc. are 
not included, AUAs are expected to leverage their existing project implementation processes and take own 
judgment for such cases. However Authentication best practices, based on Quality of service study done on 
ongoing pilot projects, are included in this document. 

This document will be updated and refined regularly to incorporate the feedback from stakeholders especially 
existing AUAs. 


3 Authentication Services Overview 


The purpose of Authentication is to enable Aadhaar-holders to prove their identity and for service providers to 
confirm the resident’s identity claim in order to provide services and give access to benefits. Aadhaar Authentication 
shall make life simpler for the resident as it is meant to be a convenient system to prove one’s identity without 
having to provide identity proof documents whenever a resident seeks a service. 

Aadhaar Authentication is the process wherein, Aadhaar number along with the Aadhaar holder’s personal identity 
data such as biometric/demographic information is submitted to UIDAI (Central Identities Data Repository-CIDR) for 
matching, following which the UIDAI verifies the correctness thereof on the basis of the match with the Aadhaar 
holder’s identity information available with it. UIDAI confirms either proof of identity or verifies the information 
provided by the resident based on the data available at the time of Authentication. To protect resident’s privacy, 
Aadhaar authentication service responds only with a “Yes / No” and no Personal Identity Information (Pll) is 
returned as part of the response. 

Aadhaar Authentication enable residents to prove their identity based on the biometric and /or demographic 
information, thus making the process of identification convenient and accurate. 

Aadhaar Authentication system supports the following Authentication types: 

1. Biometric Matching 
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a. Finger Print Authentication 

b. IRIS Authentication 

2. Demographic Matching 

3. Additional features such as One-Time-PIN (OTP) 


Biometric Matching 

Biometric Matching refers to the usage of Aadhaar Authentication for matching the biometric attributes (Finger 
Prints or IRIS) of a resident in the UIDAI database (CIDR) to the biometric data submitted by the resident on an 
authentication device and return the response in Yes (Successful Authentication) and No (Failed Authentication). 

Demographic Matching 

Demographic matching refers to the usage of Aadhaar Authentication system for matching Aadhaar number and the 
demographic attributes (name, address, date of birth, gender, etc. as per API specifications) of a resident in the 
UIDAI database (CIDR) with the data in the AUA's database or with demographic data submitted at the point of 
authentication and return the response in Yes (Successful Authentication) and No (Failed Authentication). 

One-Time-Pin 

In case of matching using One-Time-PIN (OTP) an OTP is sent to the registered mobile number of the resident 
seeking Aadhaar Authentication. The OTP shall have a limited validity of 15 min. The resident shall provide this 
OTP during authentication and the same shall be matched with the OTP at the UIDAI CIDR. Same process is 
following in case of PIN based authentication, where a PIN submitted by the resident is matched against the PIN in 
CIDR and returns the response in Yes (Successful Authentication) and No (Failed Authentication). 



4/A Till Ik 
AADHAAR 


amraQ amir/ man / Your Aadhaai No 

1111 2222 3333 




OamograpMa 

Name, gender, DoB, Age, 
Address, Mobile, Email,... 


PIN/0ITP 


YES 

OR 

NO 


Any or All 


Figure 1: Authentication Service Overview 
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4 AUA Operating Model at a Glance 


AAPHAAR 


As a part of authentication services roll-out strategy, UIDAI engages with Authentication User Agencies 
(AUAs - who would deliver services to their beneficiaries by using Aadhaar based model for verification) 
and Authentication Service Agencies (ASAs). Below table explains in detail about AUA/ASA and other 
important actors in Aadhaar Authentication eco system. 


Aadhaar Authentication 
Operating Model Actors 

Definition 

Aadhaar Holder 

These are holders of valid Aadhaar numbers who seek to authenticate their identity 
towards gaining access to the services offered by the AUA or their Sub-AUAs. 

Authentication Devices 

These are the devices that collect personal identity data (PID) from Aadhaar holders, 
prepare the information for transmission, transmit the authentication packets for 
authentication and receive the authentication results. They could be operator-assisted 
devices or self-operated devices. Examples of authentication devices include desktop 
PCs, laptops, kiosks, handheld mobile devices (microATMs),IRIS devices etc. 

Authentication User 

Agency (AUA) 

AUAs are agencies that use Aadhaar authentication to enable its services and 
connects to the CIDR by itself (as an ASA) or through an existing third party ASA. It is 
also possible that an AUA engages more than one ASA. In order to directly connect to 
the CIDR, an AUA needs UIDAI’s approval to become an ASA. An AUA could also 
transmit authentication requests from other entities that are “Sub AUAs” under it (see 
details on Sub AUA below).AUAs can also act as an aggregator offering authentication 
services to Sub-AUAs below them and may also offer value added services such as 
multi-party authentication, MIS reports and authorization to their Sub AUAs. 

Sub AUA 

Sub AUAs are agencies that use Aadhaar authentication to enable its services through 
an existing AUA e.g. IT Department of a State Government could become an AUA and 
other departments in the State would access Aadhaar authentication services through 
the IT Department as its Sub AUAs. 

Authentication Service 
Agency (ASA) 

ASAs are agencies that have established secure leased line connectivity with the 
UIDAI Database (CIDR) in compliance with UIDAI's standards and specifications. ASAs 
offer their UIDAI-compliant network connectivity as a service to Authentication User 
Agencies (see below for description of AUA) and transmit AUAs’ authentication 
requests to CIDR. An ASA could serve several AUAs; and may also offer value added 
services such as multi-party authentication, authorization and MIS reports to AUAs. 

UIDAI 

UIDAI is the overall regulator and overseer of the Aadhaar authentication system. It 
also owns and manages, either by itself or through an agency, the UIDAI Central 
Identities Data Repository (CIDR) that contains the personal identity information / data 
of all Aadhaar-holders. 


AUA Handbook 


Version 1.0 


Page 6 of 43 











AAPHAAR 


The below diagram provides an illustrative transaction flow of a service delivery request originated by an Aadhaar 
holder using an authentication device which is processed through the AUA, ASA and UIDAI channel: 


Figure 2: Transaction Flow of Aadhaar Authentication Process 
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Process 

Step 

Description 

1 

An Aadhaar Holder resident approaches a Service delivery point (e.g. PDS shop, a banking 
correspondent) and originates the service request by using the authentication devices (e.g. hand held 
devices - MicroATM). Alternatively, a service provider may approach the resident for Aadhaar 
authentication. (E.g. LPG delivery boy coming to a household for LPG delivery with a biometric 
authentication device). 

2 

An Authentication device processes the request by collecting the Aadhaar number and the 
demographic, biometrics (Finger prints and/or IRIS) and/or OTP if required of the resident, and 
subsequently sends the request to an UIDAI server. Authentication devices are deployed on the 
service delivery points either by the AUAs directly or through their business partners (e.g. Banking 
Correspondents). 

3 

AUA processes the request as per the standards and specifications of the partner ASA and UIDAI. 
AUAs have the option of partnering with multiple ASAs to connect with UIDAI database for verification 
of the residents. 

4 

ASA receives the requests from an AUA as per the specifications of UIDAI and sends the packet to 
UIDAI database for verification. 

5 

UIDAI processes the request and provides “Yes / No" response to ASA. 

6 

ASA compiles the response from UIDAI and sends the same to AUA in agreed format. 

7 

AUA processes the service request based on the response received from ASA and sends the 
response to authentication device for processing the service request. 

8 

Authentication device processes the response from AUA and delivers the service as per the business 
instructions received from an AUA. 


Please refer UIDAI website at http://uidai.qov.in/auth.html for more details on below topics of Aadhaar 
Authentication Operating Model 

• Introduction to Aadhaar authentication service 

• Engagement model: roles, responsibilities and obligations of key actors 

• Variation of the engagement model: buffered authentication 
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5 AUA-UIDAI Engagement Process 

Onboarding Process 

The below engagement process is intended to provide the interlock points between UIDAI and probable AUAs, and 
to briefly describe the common steps for adopting Aadhaar based business model. Please note that this section 
outlines the steps for a regular engagement with an Organization. The order of steps could potentially vary on case 
to case basis depending on the understanding of an organization and the support required by the organization to 
adopt Aadhaar based business model. Moreover to reduce the cycle time of the onboarding process, some of the 
activities could be carried in parallel depending on the requirements and capability of the organization. 



Figure 3: AUA On-boarding Process 
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Step 

No. 

Step 

Description 

Actor(s) 

Functional Description 

1.0 

Application 

Enquiry 

AUA 

An organization interested in becoming an Authentication User Agency 
(AUA) sends a request to enquire about the authentication services 
offered by UIDAI and to understand the process for getting access to 
Authentication services. 

Organizations (prospective AUAs) could send their requests to UIDAI for 
getting access to information on Authentication Services through: 

• Authentication ecosystem management support email 
auth.ecosvs(a)uidai.aov.in 

• Letter to UIDAI Authentication Team at Headquarters or 8 
Regional Offices 

• Authentication portal 

2.0 

Responds to 

AUA enquiry 

UIDAI 

UIDAI sends a suitable response to organization enquiry, share AUA 
related documentation and proposes to conduct a kick off session on the 
Authentication services. 

UIDAI team shares the contact details of the team managing the 
organization engagement and provides access to Authentication 
Services knowledgebase which includes the documents listed below: 

• Aadhaar Authentication Operatina Model 

• AUA handbook 

• AUA Application form 

• UIDAI-AUA Aareement 

• List of support documents and application process 

• Guidelines for AUA-ASA Aareement 

• List of current ASAs 

Note: Above document names are hvoerlinks. Complete URLs are also 
provided in Appendix 5.1. 

3.0 

Submits 
application with 
supporting 
documentation 

AUA 

Organization submits the application with supporting documents as per 
the eliaibilitv criteria provided in section 2.4.2 of Aadhaar Authentication 
Operatina Model and oraanization type as specified in section 2.0 of List 
of support documents and application process (and other documents 
published by UIDAI from time to time. The information of these 
documents will be provided to an AUA in step 2.0. 

4.0 

Verifies and 

approves 

application 

UIDAI 

UIDAI engagement team scrutinizes the AUA application and supporting 
documents as per the auidelines and specifications of Aadhaar 
Authentication Operatina Model, List of support documents and 

application process and other documents published bv UIDAI from time 
to time. UIDAI team will approve the application and inform the entity. 
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Step 

No. 

Step 

Description 

Actor(s) 

Functional Description 

5.0 

Signs agreement 

UIDAI and 

AUA 

At this stage, an AUA is expected to understand the UIDAI 
authentication services and agree to fulfill the requirements as per UIDAI 
specifications including setting up infrastructure and aligning business 
process applications to the Aadhaar Authentication application. Once 
both AUA and UIDAI are satisfied, they proceed to sign an agreement. 

UIDAI and AUA enter into an aareement as per the UIDAI-AUA 
Aareement. 

Note: At this step an AUA is also expected to have an arranaement in 
place with an UIDAI approved ASA to access UIDAI authentication 
services as explained in above section 2.0 of this document. An 
arrangement with an ASA is required by an AUA to get access to UIDAI 
Authentication database (CIDR). An AUA may enter into an agreement 
with an ASA as deemed appropriate by the two parties. To provide 
support on the aareement, UIDAI has published Guidelines for AUA- 
ASA Aareement. 

6.0 

Need support for 
readiness? 

UIDAI 

Based on interaction during the previous steps of the process and inputs 
from an AUA, UIDAI engagement team assesses the level of support to 
be provided for go live readiness. In majority of the cases the 
assessment for the level of support required by an AUA is accomplished 
in collaboration with an ASA. An ASA plays a vital role in onboarding 
and readiness of an AUA as the connectivity between AUA and ASA is a 
pre-requisite for an AUA to access Aadhaar authentication services. 

If the readiness support assessment outcome is “Yes”, please go to step 

7. 

Else, please go to step 8. 

7.0 

Conduct 
onboarding 
workshop in 
collaboration 
with an approved 
ASA 

UIDAI 

UIDAI team engages with an approved ASA to define the schedule and 
agenda of onboarding workshop and shares it with prospective AUA. 
Both UIDAI and ASA provide access to preparation material on Aadhaar 
Authentication services to better prepare an AUA for the workshop. 

8.0 

Build 

Infrastructure 

and Submits 
Request for Pre- 
Production 

Access to ASA 

AUA 

AUA builds the required infrastructure for adopting Aadhaar 
authentication with support provided by UIDAI engagement team and 
through the below mentioned mediums: 

• UIDAI Authentication Application Developer Portal 

• https://aroups.aooale.eom/forum/#iforum/aadhaarauth 

• UIDAI empanelled consultants 

• Authentication API 

• OneTimePIN (OTP) API 
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Step 

No. 

Step 

Description 

Actor(s) 

Functional Description 




• Best Finaer Detection API 

• Technoloav FAQs 

If using Biometric authentication, AUA is required to procure and deploy 
certified devices as per Biometric Devices Specifications for Aadhaar 
Authentication. 

For process of device certification and list of certified suppliers and bio¬ 
metric devices (Authentication), please refer STQC website at 
http://stac.aov.in/content/bio-metric-devices-testina-and-certification. 

Once the required infrastructure for Aadhaar authentication is ready and 
arrangements with an UIDAI approved ASA is in place, AUA will request 
the engaged ASA to send the request for pre-production environment 

access. . 

9.0 

Facilitate 

Readiness and 
Submits Request 
for Pre- 

Production 

Access 

ASA 

ASA facilitates AUAs technical readiness and subsequently send the 
request for pre-production environment access to UIDAI authentication 
support team at authsupport(a)uidai.aov.in askina for the AUA code and 
license key. 

10.0 

Assist in Pre- 
production 
Integration and 
Execution in 

collaboration 
with an approved 
ASA 

UIDAI 

UIDAI authentication support team in consultation with an ASA provides 
access to pre-production environment and enables the AUA to establish 
end to end connectivity through an ASA server to carry out 
authentication services testing. 

UIDAI Authentication support team responds to pre -production access 
request received from ASA by sharing the AUA code and license key to 
enable AUA to conduct end to end testing. At this stage an AUA is also 
linked with an approved ASA in the UIDAI backend system which 
enables the ASA and UIDAI to process authentication transactions 
transmitted by an AUA. 

11.0 

Conducts End to 
End Testing with 
an approved 

ASA, Audit and 
Submits Request 
for Go Live 

AUA 

AUA engages the respective ASA and conducts end to end testing on 
UIDAI pre-production environment. 

Post successful end to end testing AUA engages an Auditor to conduct 
the compliance audit as per Aadhaar Authentication Standards and 

Specifications. 

Subsequently AUA completes the go live checklist and submits the 
request for go live with the following documents: 

• Go Live checklist (Provided as part of the AUA Application 
form). 
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Step 

No. 

Step 

Description 

Actor(s) 

Functional Description 




• Audit certificate as proof of compliance to current UIDAI 
standards and specifications. 

12.0 

Approve and 
assist in Go Live 

UIDAI 

UIDAI engagement team scrutinizes the AUA go live request as per the 
Go-Live checklist and supporting documentation and seeks internal 
approvals for Go Live. 

UIDAI provides access to AUA authentication admin portal for accessing 
AUA code and License Key. 

13.0 

Production 

release and 

operations 

management 

AUA 

AUA establishes a production release and operations management 
mechanism. 

Note: For any Technical Operations Support for live AUA, please contact 
UIDAI bv sendina an email to authsuDDort(S)uidai.aov.in or bv callinq at: 
011-23462644. 
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6 Steps for Implementing Aadhaar Authentication 


Implementing Aadhaar authentication for service delivery has a lot of similarity with a typical business and IT project 
based on Software Development Life Cycle (SDLC) with standard stages as Analyze, Design, Develop, Test, 
Implement and Operate. 

The diagram below represents a consolidated view of the sections of this handbook that outlines the illustrative 
stages involved in implementing Aadhaar based model for service delivery, and the roles played by business and 
technology teams. Please note that the detailed steps in each of the implementation stages outlined in this section 
are illustrative and could potentially vary on case to case basis depending on the capability and team structure of an 
AUA for adopting the Aadhaar based business model. 


Initiation 


Readiness 


Implementation 


Compliance 


Roll out 


BUSINESS 


TECHNOLOGY 

Aadhaar Based Business 
Model 


Technology Roadmap 



Define Aadhaar Enabled 
Processes 


Technology Infrastructure 



Aadhaar Enabled Process 


AUA Server and Device 

Development 


Applications 



Audit 


End to End Testing 



Go Live and Training 


Release and Operate 


Figure 4: Aadhaar Implementation Stages 


6.1 Initiation 

This is the first stage where an organization, interested in becoming an AUA, initiates the process of incorporating 
Aadhaar authentication in their business model for services delivery. 

Key steps at this stage are listed below: 

• Definition of Aadhaar Based Business Model 

• Definition of Technology Roadmap 

Outcome of this stage would be a well-defined implementation roadmap with activities and stakeholders (Internal 
and External Teams) responsibilities from Dayl of project implementation to Go-live. 


AUA Handbook 


Version 1.0 


Page 13 of 43 
































































6.1.1 Aadhaar Based Business Model 


A well - defined plan for integration of Aadhaar into AUA business solution for service delivery is critical for 
harnessing value from Aadhaar authentication. AUAs are expected to start with the step of building an 
understanding of the functionality offered by Aadhaar authentication and thereof analyze the business direction to 
define the Aadhaar implementation scope. 

Key business model milestones should include the following: 

• Formation of a Joint Working Group (with members from AUA Business and Technology Team, ASA 
Business and Technology Team, UIDAI, Authentication device vendors etc.) 

• Identification of business areas for Aadhaar implementation 

• Selection of domain specific process for pilot implementation 

• Linking of Aadhaar into selected business process 

• Definition of roll out strategy including selection of pilot geographies based on the Aadhaar penetration i.e. 
areas with high % of Aadhaar enrolments 

• Definition of process for procurement of certified authentication devices 

• Definition of audit and security specifications 

• Definition of training requirements 

6.1.2 Technology Roadmap 


In this stage AUA defines the key technology milestones as part of the business project plan for implementation of 
Aadhaar based solution. An AUA is expected to identify the core team based on the understanding of Aadhaar 
Authentication for laying out the implementation plan with defined delivery milestones. 

Key technology milestones should include: 

• Identification of technology team to form a part of the Joint Working Group 

• Procurement of hardware and software 

• Environment setup 

• End to end Connectivity with ASA and other business partners (e.g. Sub-AUA, if any) 

• Server application design and development 

• Device applications design and development 

• End to end testing with UIDAI pre-production environment 

• Implementation of MIS and fraud monitoring 

• End to end testing with UIDAI production environment before roll out of the service to end customers 
Production Release 

• Operations Management 

6.2 Readiness 

6.2.1 Define Aadhaar Enabled Processes 

To integrate Aadhaar, an AUA needs to analyze the As-ls business processes for identifying the business areas 
where Aadhaar Authentication based service delivery could be adopted. 

To successfully implement this, an AUA needs to focus on various aspects, especially: 
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1. To-Be domain specific processes 

2. Linking Aadhaar with existing Resident ID (Also referred to as Aadhaar Seeding) 

3. Ensuring Inclusion and taking measures to avoid service disruption (Also referred as Exception Handling) 

4. Fraud Monitoring 

To-Be Domain Specific Processes 

AUA would be required to define the to-be processes for service delivery. Key aspects of the to-be processes are: 

• Analyze As-ls process and process challenges 

• Identify processes which can be modified to leverage the benefits of Aadhaar Platform (For example: ID 
Verification) 

• Analyze Service Delivery Data to understand the data structure differences across silos, formats in which 
data exists 

• Analyze the way data is shared among various process owners during service delivery 

• Identify common data model required for service delivery 

• Definition of the business rules for acceptance of Aadhaar based authentication for service delivery e.g. 

■ Rules for cleansing the resident/beneficiary databases through the process of Aadhaar linking. 
E.g. During the process if there are more than 1 record having similar name and address with 
different resident IDs, all the residents are required to physically report and may also be required 
to give biometric details for Aadhaar mapping. 

* Rules for processing of the authentication request and handle the response for service delivery 
etc. 

Linking Aadhaar with Existing Resident ID (Also Referred to as Aadhaar Seeding) 

Delivery of services through Aadhaar based authentication is dependent on linking of the Aadhaar number with 
existing Resident ID e.g. for direct transfer of government subsidy to a beneficiary will require mapping of Aadhaar 
number with the scheme entitlement ID and the bank account number of the beneficiary resident. The objective is 
not to replace the currently used unique identifier of the customers/ residents/ beneficiaries with Aadhaar but the 
objective is to seamlessly enable Aadhaar authentication without impacting any other interface that the service 
providers maintain with their customers. 

Therefore, Aadhaar seeding is one of the most critical steps of the business readiness stage that could be achieved 
through a combination of several strategies, as no single solution will apply to all cases. It is essential that every 
seeding process is thoroughly analyzed and planned before proceeding with actual seeding. While it is the 
responsibility of the service providers to seed their service delivery databases with Aadhaar, UIDAI will support by 
providing sample tools, best practices and consulting advisory on request. 


Primarily there are two ways of seeding of service delivery database with Aadhaar number: 



Description 

Example 

UIDAI Sample 
Tools 

1. Top-Down 
method 

This is a method using which 
Service Delivery data records 
are matched with Aadhaar 

enrollment data 

(KYR/KYR+/EID-UID) in order 
to find a suitable match. Upon 
finding a match, Aadhaar 

1. MGNREGA Job Card number was 
captured as KYR+ field at the time of the 
enrolment. The fields Job Card Number 

and Resident name can then be used 
along with UID number available from EID- 
UID XML files to find a matching unique 
record in MGNREGA database. 

State Resident 

Data Hub (SRDH) 

- Batch Seeding 
Module for State 
Governments. 

Ginger - a tool built 
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Description 

Example 

UIDAI Sample 
Tools 


number is seeded into the 
service delivery database. 

Exact match or best match 
strategies may be used in this 

case. 

2. A combination of various fields from 
Service Delivery database records is 
matched with SRDH records to get the 
best matches, and a verifier may select the 
right record/UID for seeding. 

internally at UIDAI 

2. Bottom-up 
method 

This involves creation of touch 
points with the residents where 
the residents voluntarily or in 
response to service provider’s 
call initiates inclusion of their 
UID in service delivery 
databases. 

1. A department can leverage one or more 
channels of communication with the 
residents in order to capture their Aadhaar 
numbers e.g. Document collection camps 
where Residents are expected to hand 
over copies of Aadhaar letter and 
registration form with the service provider 
(ex. Ration card). Service provider later 
updates the service delivery database 
based on the information supplied. 

SRDH - Manual 
Seeding Module 


Please refer UIDAI website at http://uidai.qov.in/imaqes/aadhaar seeding v 10 280312.pdf for more details on 
below topics on Aadhaar Seeding: 

• Aadhaar Seeding Strategy 

• Why Aadhaar seeding is required 

• Pre-requisites of Aadhaar Seeding 

• Seeding categories 

• Common challenges 

• Case studies (with sample Oil and Marketing Companies and Banks Approach) 

• UIDAI seeding utility- Ginger 

Ensure Inclusion and Avoid Service Disruption 

In any identity verification program it is important to decide what exception rate is acceptable and how to handle the 
exception cases for 100% inclusion of the residents for service delivery. Like any other technology, biometrics 
based authentication has certain limitations. There will always be a set of population who will not be able to 
(temporarily or permanently) authenticate through biometric authentication system due to multiple reasons, such as: 

• Residents with missing biometric characteristics; for example, no fingers 

• Residents engaged in hard manual labor (such as construction, mine workers) having all of their fingers in 
extremely poor condition with respect to fingerprint quality 

• Residents having illness such as cataract problem, burnt/cut fingers 

• Extreme environmental conditions with direct sunlight, high humidity and dryness 

• Very young (children) and very elderly population having undefined features, soft and wrinkled skin 

To ensure that such genuine residents are not denied service delivery, and the existing service delivery is not 
interrupted by introduction of Aadhaar based solution, an AUA would require exception handling process i.e. usage 
of alternative ways of verifying the residents for service delivery. UIDAI recommends implementing a multi factor 
authentication (also known as Federated Authentication) where Aadhaar authentication can be used in conjunction 
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with AUAs domain/application specific authentication schemes. Some solutions could be using alternate biometric 
modalities, allowing multiple attempts, operator authentication, using demographic / OTP based authentication etc. 
Adopting federated model is also expected to aid handling of biometric exceptions. 

Some examples of the exception handling process are listed below: 

• One of the banks has advised its Banking Correspondents (BCs) to keep withdrawal slips at the point of 
service delivery. Genuine residents who do not succeed in biometric authentication are asked to fill up the 
withdrawal slip and sign/give thumbprint. The withdrawal slip is then countersigned by the Mukhiya / local 
representative. On his next visit to bank branch, the BC gets cash from the bank and hands over to the 
resident. 

• The Food &Civil Supplies Department of a State Government has recorded mobile numbers of all its 
beneficiaries (almost 98% have mobile phones). In case of biometric failure, a One-Time-PIN (OTP) is sent 
to the recorded mobile number and authentication is done basis OTP success. This OTP is different from 
the OTP authentication offered by UIDAI. For the remaining 2% residents, manual authentication is done 
through existing ration card of the resident. 

Besides biometric limitations, there could also be occasional network challenges. Online authentication essentially 
requires network connectivity. For cases where connectivity is intermittent or connectivity is a little distance away, 
UIDAI proposes a solution called “buffered” authentication wherein authentication request may be “buffered” (or 
queued) on the device until a pre-specified period of time, which is currently 24 hours, and then sent to CIDR for 
authentication when connectivity is restored / available. 

Note : The exception handling mechanisms should be backed up by reliable features to log and track requests 
handled through exception handling mechanism to prevent any fraud attempts. 

Fraud monitoring 

One of the key benefits foreseen of Aadhaar authentication is elimination of ghosts and fakes and ensuring that 
services are delivered to the right beneficiaries. However, as explained in point 3 of this section, due to limitations of 
biometric authentication, AUAs need to deploy exception handling mechanism. This in turn could lead to potential 
misuse of exception handling mechanism to divert services to other parties and deny services to actual 
beneficiaries. 

AUAs that currently face problems of diversion of services/goods to non-deserving parties especially need to ensure 
that the exception handling mechanism is backed by a fraud monitoring mechanism. 

In order to avoid security issues, inconvenience to resident and to streamline the process for exception cases, it is 
strongly recommended that the authentication application should have an option to record these cases along with 
AUA/operator details for better reporting, analysis and traceability. The number of manual override/exception 
handling attempts should be tracked and only limited number of manual overrides could be allowed per day per 
terminal to prevent operator malpractice. 

An example of fraud monitoring working in tandem with exception handling is as follows. An LPG delivery 
organization that uses biometric authentication (but allows for manual overrides in case of biometric rejects) 
requires the operator to log into the system before start of service delivery through secure credentials. Upon 
observing high biometric reject rates, it started analyzing biometric reject percentages by delivery boy. Certain 
delivery boys appeared to have much higher reject rates than others. When this feedback was given to the 
respective dealers and data closely monitored, the manual overrides / biometric reject rates came within acceptable 
limits. 
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6 . 2.2 Technology Infrastructure 

Similar to any other technology project, for implementation of Aadhaar authentication an AUA would need to set up 
the IT infrastructure. The following section lists the indicative resources (hardware, software, and manpower) 
required for building applications for processing Aadhaar authentication. AUAs are required to create their own 
actual requirements based on services they plan to offer, choice of technology, and existing resources within their 
IT system. 

Hardware to be provisioned by AUA is listed below: 

• It is recommended that AUA has a lease line or a dedicated connectivity with ASA network. 

• Bandwidth requirements should be computed based on the expected volume of transactions from Sub 
AUAs/Devices. 

■ Roughly about 5K average bandwidth is required for each API call. 

* Handling about 1 Lakh transaction per hour requires about 28 transactions per second (tps) on an 
average. Considering 30-40% spike, bandwidth for about 40 tps needs to be planned for. This turns 
out to be around 1.6 Mbps (40*5K*8 bits/sec). 

■ AUAs may start with a 1 Mbps link and expand as volumes increase. 

• Within AUA Network 

■ Network equipment’s - appropriate network equipment’s to connect from Sub AUAs/Devices and 
further to ASA. 

■ One server (dual quad-core blade/rack servers with 64 GB RAM) with cluster setup having two or 
more nodes or at least 2 servers (dual quad-core blade/rack servers with 32 GB RAM 
recommended) for hosting AUA server within AUA data center in an active-active (preferred) or 
active-standby mode. Server sizing needs to be done by AUA based on actual AUA server 
performance and expected volumes. 

■ HSM Box is recommended to protect digital signature and to handle large volume digital signing. 

* Firewall server - for securing network from Sub AUA to AUA and then AUA to ASA. It is suggested 
that two different firewall products from two different vendors be deployed for better security. AUAs 
could use existing firewalls in their network for this purpose. There is no requirement for a 
dedicated firewall. 

■ Other security appliances/servers - In addition to firewall, it is recommended that AUAs provision 
for network intrusion detection and prevention systems as well as anti-virus and anti-malware 
systems to ensure AUA network is protected from attacks. 

■ If auditing is done using a database, at least 2 servers to install and configure audit database. To 
avoid audit database becoming a single point of failure, it is recommended that database be 
configured in active-active or active-standby mode. 

* Storage required for maintaining audits for at least 6 months. Considering 5K audit size per 
transaction, for 10 Lakh transactions a day, ASAs require 5GB of storage size. If AUAs retain audit 
logs online for, say, 1 month, then 150GB online storage is required per month beyond which it 
could be moved to tape. 
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• AUA Authentication Devices 

■ Authentication devices are expected to be used for a variety of purposes and would need to be 
specific to every AUA's requirements. 

* Authentication request (Biometric/ Demographic/ OTP) could be initiated from any kind of device 
capable of creating authentication packet as per UIDAI's authentication APIs. 

■ For biometric authentication, sensor and extractor combination certified by STQC should be used in 
the devices. 

■ UIDAI specifications include sensor & image extractor requirements and device suitability to 
general Indian operating conditions. The specifications and the certification procedure may be 
accessed from STQC’s website through this link - UIDAI Authentication Device Specifications 

■ Besides the sensor-extractor specifications provided by UIDAI, AUAs may specify additional 
requirements such as multi language support, voice support, form factor etc. Various device 
vendors are expected to incorporate the certified sensor-extractors in device models / form factors 
based on AUA’s needs. AUAs are expected to select form factor based on requirements such as 

• Service delivery and deployment needs i.e. level of Mobility is required etc. 

• Network availability in locations where devices are deployed, AUAs may also consider 
opting for solutions such as dual SIM, external antennas etc 

• Suitability to specific environmental conditions such as, hot/cold desert, high humidity areas 
etc. 

Some possible form factors in which biometric authentication devices may be deployed include the devices 
listed in the below table: 


Hand-Held / PoS Device such as MicroATMs 



USB device connected to PC 

* 

i L=J 

Mobile phone with biometric sensor 


V/ m 
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Kiosks such as ATMs 



IRIS Device 



Mobile Phone 

mmm I 


Software to be provisioned by AUA is listed below: 

• Server class Operating System for all machines deployed. 

• Class ll-lll Digital Signature. For details on procurement, please read latest API documentation. 

• AUA server software as described in the AUA Server Architecture section. AUA server functionality could 
be built using off-the-shelf open-source/commercial tools. 

• Firewall software - it is suggested that, when using multiple firewalls, AUAs use products from different 
vendors to strengthen security. AUAs can choose to use existing firewalls within their IT system for this 
purpose. 

• Database software (if auditing is database based) - if auditing is done in an RDBMS, then database 
software is required. AUAs can choose any open-source/commercial database based on their preference. 

• Monitoring software to effectively monitor production system. Any enterprise monitoring software (EMS) 
could be used. AUAs can choose a commercial/open-source tool based on their preference or use an 
existing one that may be already in place within AUA IT system. 

• Other related software tools for managing network devices, servers, and database, backup, replication, 
reporting tools for MIS purposes, integration to billing software for AUAs to bill Sub AUAs/device vendors. 

Manpower to be provisioned by an AUA is listed below: 

AUAs are responsible for all the devices, servers, and the network until the ASA network. If AUAs are offering 24 x 
7 service availability to their Sub AUAs/devices, then network needs to be monitored and managed using people in 
multiple shifts. Appropriate team needs to be put in place to handle operations, security, and support to their AUAs 
to ensure high quality of service. 

Key resources within AUA organization are listed below: 

• Network administrators 

• System administrators 

• Database administrators 
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• Backup administrators 

• Security administrators 

• LI/L2/L3 support team 

• Operations and Project Management team 


6.3 Implementation 

6.3.1 Aadhaar Enabled Process Development 

At this stage AUA implements the Aadhaar enabled processes by deriving inputs from the readiness stage where 
the to-be processes are defined. In most of the cases an AUA would be engaging Business, IT teams and the 
Consultants / Software Solution Providers for development of the processes. 

An AUA is expected to develop processes to manage the Aadhaar based authentication for service delivery in lines 
of process areas explained in the readiness section. So an AUA would ensure the development of applications for: 

1. To be domain specific processes 

2. Linking Aadhaar with existing Resident ID (Also referred as Aadhaar Seeding) 

3. Ensuring Inclusion and avoid service disruption (Also referred as Exception Handling) 

4. Fraud Monitoring 

One of the key and mandatory areas of process development is Resident onboarding, where in business processes 
are put in place for information, education and communication of the residents availing services through Aadhaar 
based authentication. AUAs are expected to develop applications for helping the residents to understand the 
changes in service delivery process due to integration of Aadhaar Authentication in their business models e.g. need 
for the resident to link his Aadhaar number with the existing resident ID’s, relevance of Aadhaar number and 
existing IDs / proofs of the resident. AUAs are required to develop processes for building and managing teams 
(service delivery operators) who would be interacting with residents. The resident onboarding process should also 
focus on Do’s and Don’ts of Aadhaar authentication for both service delivery operators and residents. 

To assist AUAs in developing processes to implement Aadhaar based authentication, UIDAI has published 
reference material that would provide assistance to AUAs while interacting with residents and also better enable the 
AUAs to inform and educate the residents about their biometrics and authentication process. The reference material 
is available at UIDAI website accessible at www.uidai.qov.in/auth and UIDAI developer portal accessible at 
https://developer.uidai.qov.in/site/home . 

UIDAI also provides assistance to ecosystem partners for development of processes and applications through: 

• UIDAI's empanelled Consultants and Software Solution Providers to provide assistance to potential AUAs. 

• Consultant would provide services on Process Reengineering, Project Management and 
Implementation support to AUAs for facilitating integration of their processes with Aadhaar. 

• Software Solution Providers would help in designing Aadhaar enabled Applications. 

For details please refer 

http://uidai.qov.in/imaqes/FrontPaqeUpdates/final empanelment list 30 may 2011.pdf 

• ICT Assistance 
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• ICT Assistance is provided to States for engagement of consultants and service providers for defining 
and developing Aadhaar applications 

• UIDAI Support Team and Tools 

• Team will facilitate conceptualization and defining areas of Aadhaar usage jointly with AUAs and 
provide assistance in identifying applications solutions and necessary linkages. 


6.3.2 AUA Server and Device Applications 


AUAs can offer “Sub AUA/device application” multiple protocols and options for connecting their solution to Aadhaar 
system via ASA. 

At a basic level, AUA services are: 

• Preparing Auth request based on the latest API published by UIDAI using inputs from Sub AUA/devices 
(uid, tid, sa, data, hmac etc). 

• Digitally Signing Authentication request 

• Routing Authentication Request to ASA 

• Receiving response from ASA and forwarding the same to Sub AUA/device. 

In most of the cases AUA will be a service providing agency like a bank. So AUA server application development 
will be part of their business application development. There will still be few cases where AUA will only provide pure 
authentication services. It is advisable that in both the cases AUA server application is built separately and used as 
a service. AUA server application should have broadly following components/services: 

• Validation component to validate input received from Sub AUA/Devices to prepare Auth request correctly. 

• An auditing component to store request/response/failure and other key information like uid, tid, auth request 
date time, auth response date time etc. for auditing purposes. 

• An independent component for digital signing of authentication request 

• A component for MIS and Fraud Monitoring to generate various reports for stakeholders (UIDAI, ASA, Sub- 
AUA etc.) and monitoring service quality. This will also help in preventing misuse of services. 

• An Authentication/Best Finger Detection (BFD) etc. message creator component to form request messages. 

• An AUA request/response handler to handle request receive from Sub-AUA / Devices and response 
received from ASA. 

AUA need to expose services (Web service recommended) to Sub AUAs /devices to place auth request to CIDR 
through ASA. Network connectivity between Sub AUAs /devices to AUA server can be through Internet, GPRS, and 
Broadband etc. in a reliable and secure fashion. 


6.3.3 AUA Server Application Architecture 


Following diagram depicts a high level architecture of an AUA server: 
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Figure 5: Illustrative High Level Architecture of AUA Server 


At a high level the flow of API request and response is as follows (point number below corresponds to number 
within the circle above): 


1. Multiple devices or Sub AUAs should be supported 

2. Connectivity between Sub AUAs and devices 

a. Network connectivity from devices to AUA server (Internet, GPRS, Broadband etc) in a reliable, 
secure fashion. 

b. Communication protocol can be the choice of AUA and Sub-AUA. Indicative options are mentioned 
in the diagram above (Figure 1). 

c. To make communication more secure VPN option could also be used.(suggested option in case of 
a Sub AUA) 

3. AUA server (depicted in the light blue box with dotted line border) 

a. This should be built to support a “horizontally” scalable deployment on one or multiple servers, so 
that as the transaction volume increase, additional servers can be added to handle the load. 

b. A generic AUA server should provide multiple protocol support as shown in the diagram above 
(providing AUAs a choice of protocols). 

Components 4, 5, and 6 are parts of AUA server and are described below: 


4. If AUAs wishes to offer multiple choices in terms of how Sub AUAs/devices actually communicate with AUA 
server, it is suggested that, a well-designed layer handling various protocols be built. 

a. A pluggable set of protocol handlers could provide standard protocols such as HTTPS, JMS, etc. to 
be used for incoming communication from Sub AUAs/devices. 

b. Generic AUA application can provide wide range of data format (XML, binary formats such as ISO- 
8583 in the case of financial transactions, JSON, csv, etc.) to fulfill need of various kind of Sub 
AUA/devices. 

5. Once the data is received in the AUA server, server needs to do the following: 
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a. Validate the input data to ensure compliance to Aadhaar data definitions as well as to eliminate 
issues such as SQL-injection etc. 

b. After validation, format it to an XML format complying with Aadhaar API specifications. 

c. Sign it digitally 

d. Forward to ASA using appropriate protocol supported by ASA. 

e. Audit Transaction into an audit database. 

f. Format back response xml and send back to Sub AUA/Device specific format using an appropriate 
protocol adapter. 

6. Network between AUAs and ASA. 

a. This could be any kind of secure network depending on the needs of AUAs. 

b. UIDAI suggests that this be a private leased line to have better control of availability, bandwidth, 
reliability, and security. 

c. UIDAI mandates that communication between AUAs and ASAs for sending Aadhaar API requests 
and responses be secure. 

d. Choice of specific protocol and security standards depends on the domain and application AUAs 
and ASAs are using. 

e. Based on the application needs of AUA, API requests could be sent using a synchronous protocol 
(such as HTTPS) or an asynchronous protocol (such as a message queue). 

f. For AUAs who are new and starting afresh, UIDAI suggests using HTTPS over a leased line to 
communicate between AUA and ASA. 

6.3.4 Setup Environment 

It is recommended that an AUA should have separate environments for development, testing and production. 

UIDAI provides support to AUAs at all three stages for development, testing and production in line with the below 

table: 



Development 

Pre-production 

Production 

Prerequisite to 
access UIDAI 
environments 

No prerequisites- All 

prospective AUA can access 
the UIDAI development 

environment 

UIDAI-AUA Agreement & 
Established connectivity with 
an UIDAI approved ASA 
having leased line 

connectivity with UIDAI in 
place. 

Approval on UIDAI Go 
Live checklist and 

supporting documents 

Support from 

UIDAI 

•API’s and Technical FAQs 
•UIDAI Developer portal with 
details of AUA Handbook, 
Sample code, Vanilla 

Applications etc. 

•Gooale aroup for technical 
and application queries. 

•List of approved ASAs with 
contact details 

•Facilitates end to end 
testing with CIDR once 
ASAs provide staging test 
AUA code and license key 
to AUAs 

•Google group for technical 
queries 

Provides AUA code and 
license key post Go Live 
approval 
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6.3.5 AUA Applications 


AUA applications can use Biometric (Finger Print), Demographic and OTP (One Time PIN) based authentication in 
its business application. As shown in the architecture section above for all type of applications, solution should be 
modular and configurable. Module/Component based solution will help in making application loosely coupled and 
hence provide a lot of flexibility in maintenance and upgrades. It is recommended that business application is not 
tightly coupled with Authentication application. In all scenarios authentication will only form a part of the total 
solution, so authentication functionality should be ideally developed as a standalone service that could be 
consumed as and when required during the service delivery process. 

For biometric authentication an AUA is required to build the following applications on the authentication devices: 

1. Best Finger Detection Application 

2. Finger Print Authentication application 

3. IRIS Authentication Application 

4. OTP 

6.3.6 Best Finger Detection (BFD) Application 


Best finger detection (BFD) application will determine the best fingers of the resident by analysing all the ten fingers 
of the resident. Recent studies have indicated that for most of residents, best fingers have higher probability of 
authenticating successfully in least number of attempts. As a result of the BFD, the residents are informed about 
their two best fingers (Rank 1 and Rank 2) which could be used for successful authentication. BFD is done only 
once before the first biometric authentication (irrespective of which AUA). If a resident forgets best fingers, he/she 
can still try authentication with other fingers (non-best fingers) or can request the AUA for BFD again. 

Key benefits of BFD: 

• Provide consistent higher authentication accuracy. 

• Best finger detection improves reliability of authentication. 

• Identify resident who are likely to need two fingers for authentication. 

• Identify residents who may need to update their biometrics. 

• Identify residents who may need to use alternate authentication mechanisms due to inherent poor finger 
quality. 

BFD finger capture process 

The following section outlines, the process of finger captures in order to determine best fingers. The same is 
outlined in Figure 6. 

1. Capture one finger at a time in order specified in Figure 6. 

2. One at a time, capture ten fingers. Ensure labelling is properly done. As a best practice following order is 
suggested Left little, Left Ring, Left middle, Left index, Left thumb, Right Thumb, Right index, Right middle, 
Right ring and Right little fingers in that order (refer Figure 6). 

3. While capturing any finger, its NFIQ should be displayed in the client application. 

4. Once the best attempt is captured for all fingers, application forms the input for the BFD API as specified in 
the Aadhaar Best Finger Detection (BFD) API 1.6. 

5. Application invokes the BFD API through AUA server (similar to authentication process). 
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6. Based on the response, provide a printed receipt to the resident indicating the best fingers of the resident. 

7. Once best fingers are detected among ten fingers, resident proceeds to conduct authentication thereon 
using the best fingers.In case, best fingers are not detected even after providing all 10 fingers, resident can 
attempt the process again or follow the error codes to take appropriate action as per the AUA guidance. 


. Put only 

Finger kU«Lm^' PM finger 



Right way to place fingers 

Finger Thumb 



Figure 6: BFD Capture Process (1-10 Fingers) 
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Figure 7: BFD implementation Sample Screens for a Point of Sale/ Micro ATM Based application 
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Figure 8: BFD Sample Screen for a Computer Based Application (1) 



Figure 9: Sample Screen for a Computer Based Application (2) 

Result of BFD Application 

BFD server at UIDAI end processes incoming requests to look for best fingers among incoming fingers. Best finger 
process is expected to indicate all good fingers apart from best fingers as well as indicate suggested actions in case 
no good fingers are found. BFD application feedback helps resident to clearly identify which of his/her fingers are 
good for authentication. Resident is expected to use his/her fingers in the order of rank for authentication. 

The BFD Application must be able to distinguish between a finger which was not sent for BFD and finger 
which was found to be of poor quality. 

• Return code-“00”- Successful. Resident’s two best fingers indicated with indicated with rankl and 2 so no 
further action is needed. Other fingers which can also be used for authentication is ranked in ascending 
order. Fingers not ranked cannot be used for authentication. 
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• Return code - “01”- No best finger found - Fingerprint quality of resident good. Check if Aadhaar number if 
entered correctly. Repeat BFD by paying attention to order of finger scanned. If Aadhaar was entered 
correctly, sequence of fingers scanned was right, then, biometric update will be needed for the resident 
through Aadhaar update process. 

• Return code - “03”- No best fingers found. Check if Aadhaar number if entered correctly. Repeat BFD by 
paying attention to order of finger scanned. If Aadhaar was entered correctly, sequence of fingers scanned 
was right, then one possibility is resident fingerprint quality is very poor for authentication. Resident may 
obtain authentication results with very low reliability. 

• Return code - “04”- Biometrics are not present in gallery, and user should go for re-enrolment. 

• Return code - “99”- Biometrics related to Aadhaar number is not present in authentication database and is 

being populated. Try after some time. If the error persists, please refer to error code in the CONSOLE and 
report to technical support. 

• For all other failure scenarios, “99” is returned - “Server cannot determine what action you should take, 

please look at the error code and see what needs to be done”. The error code, like in Authentication, will 

provide the context for what has happened on the server. For example, if error code was 510 - Invalid 
XML, the action is to fix the application code. Report the error code to technical support. Try repeating the 
test. 

Actionable feedback message in English in case resident or operator needs to take specific actions. BFD 
applications should display message to enable operator and resident take appropriate actions. 

BFD tool implementation 

Authentication devices using biometric authentication implementing this BFD API should have the user interface for 
capture and sending as described below: 

• Operator is expected to examine all ten fingers of the resident. 

• In case, fingers are excessively dry, wipe with wet cloth 

• In case, excessively wet, wipe it dry 

• In case, if fingers are not clean (dust/oil/grease), operator can request resident to clean the fingers. 

• Resident/operator needs to clearly know which finger to capture and should be visible on screen. 

• Operator should ask resident to keep finger on the device until its get appeared on the client app screen. 
Operator should also make sure that there would be a green light blinks on device while capture the 
fingerprints. 

• There must be options to rescan after the capture is complete. 

• Capture high quality fingers up to 3 attempts and application must pick up highest NFIQ image (if possible 
NFIQ 1 & 2). 

• Application should remember the finger position because it has to be sent alongside NFIQ for every finger 
as part of BFD API input. 

• Application must do local matching to avoid same finger being sent against different positions and to also 
ensure same finger is indeed used during multiple attempts. 

• Application should send only templates and not images. 

• Provide for exception where resident may not have all ten fingers. This can be achieved by providing skip 
flag for every finger. Operator can mark either mark fingers as skip or not scan/label. 

• Provide an option to buffer the transaction in case the connectivity is not there and replay from database. 

• Application must not store any unencrypted data that involves resident information including biometrics. 
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• BFD application must provide a printed receipt Ul indicating BFD output details preferably with a picture of 
the hand 

• Buffered/online transaction receipt needs to be provided to resident. 

• Receipt needs to indicate rank as per response for each response and any action code/messages, if any. 
6.3.7 Finger Print Authentication Application 

In accordance with the API, authentication application on the MicroATM can package single finger or two finger 
minutiae records in the same transaction. Syntax for packing single or two finger minutiae records is elaborated in 
the Aadhaar Authentication API Specification. 

Application is expected to implement two finger authentications as part of the fingerprint authentication module. 

In the event of online Aadhaar authentication transaction, flow of events for carrying out two finger authentication is 
as follows. 

• After capturing the first best finger, the minutiae record is sent to UIDAI. A copy of the minutiae record for 
the first finger is retained in memory (as against stored on disk). This is single finger authentication. 

• If the authentication transaction is successful, then the minutiae record is deleted from memory and 
application proceeds to next stage post authentication. 

• If the authentication transaction is unsuccessful, then resident is requested to provide second best finger 
and minutiae record from first finger (retrieved from memory) as well as minutiae record from second best 
finger is submitted for two-finger authentication. 

This completes one attempt of two finger authentication cycle. If the two finger authentication is unsuccessful, the 
same process can be repeated in order to enable successful authentication. 

Finger print authentication process 

• Operator is expected to examine fingers of the resident. 

o In case, fingers are excessively dry, wipe with wet cloth 
o In case, excessively wet, wipe it dry 

o In case, if fingers are not clean (dust/oil/grease), operator can request resident to clean the fingers. 

• Displaying the number of minutiae points captured and NFIQ of image (when possible) helps operator to 
improve the quality of the image capture. 

• Quality checking software (NFIQ) can be implemented on the device helps measure quality of capture. 
Capture high quality fingers up to 3 attempts and application can highest NFIQ image to enable more 
reliable authentication. (If possible, prefer NFIQ 1 & 2). NFIQ computation is expected to take more than 5 
seconds on existing MicroATM implementations. Hence computing NFIQ is not mandatory and other means 
to provide quality feedback such as number of minutiae in the captured sample can be explored. 

• Operator should ensure that for the residents BFD have already done. In case residents have not done the 
BFD, the operator should do BFD first. Please refer section 5.2.3.2 to see the BFD process. 

• Improving authentication reliability by providing feedback regarding capture quality - Submitting minutiae 
records with less number of minutiae points’ risks unsuccessful authentication. Headers of ISO minutiae 
record provide information related to number of minutiae points. When less than 20 minutiae points are 
captured, operator should capture once again in order to increase the number of minutiae points. Up to 
three capture attempts can be conducted in order to increase the minutiae points in the captured image. 

• In case of connectivity issues, two fingers can be captured at once and two finger authentication 
transactions can be carried out in buffered mode. 
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• During multiple attempts, simplified two finger scheme can be implemented which is detailed below. By 
retaining the last captured fingerprint minutiae in memory, application can only request one best finger and 
form two finger authentication requests. Sample capture flow process is indicated below. 

o Capture 1 - 1 st best finger - single finger auth transaction 

o If fail, Capture 2 - 2 nd best finger - two finger auth transaction ( using capture 1 and 2) 

o If fail, Capture 3 - 1 st best finger - two finger auth transaction ( using capture 2 and 3) 

o If fail, Capture 4 - 2 nd best finger - two finger auth transaction ( using capture 3 and 4) 

• This flow helps resident to achieve authentication in minimal number of captures. 

• Application must not store any unencrypted data that involves resident information including biometrics. 

• Resident is expected to place the finger on the sensor platen in the figure below. Resident is expected to 

place the finger as straight as possible and should be able to apply mild pressure to enable good quality 

capture. Sensors must be mounted on the device in order to enable good quality capture both in table top 
mode as well as handheld mode. 




• Figure below indicates improper ways to for resident to place finger on the sensor. 

• Devices can integrate the prompts on the screen (where picture display is possible) indicating best ways to 
place fingers on sensor to prompt the resident. 

• Training capsule provided on the device for operator training, as sequence of images or videos to enable 
best fingerprint image capture. 

• Prompting the resident during fingerprint capture - resident and operator benefit from prompting signals 
implemented on device/sensor and helps in achieving high quality fingerprint captures. 

o Prompting can be achieved with a sound to signal starting time of capture 

o In case, option to light up sensors exists or providing lights around the sensor is possible, same can 
be considered. 

o Signaling end of capture to operator is important and helps during multiple captures. 

• Authentication should not attempt to alter either minutiae or image record. 
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6.3.8 IRIS Authentication Application 

Authentication focuses on matching a person’s identity based on the reliability of a credential offered. Various 

agencies have different requirements for the degree of assurance required while authenticating residents. 

When using IRIS, at a high level, there are three distinct activities: 

1. Authentication device capture the IRIS image and send to the UIDAI server along with AADHAAR number 
for authentication. 

2. The IRIS image and AADHAAR number is matched with the available templates, provided at the time of 
enrollment, in the Data Center. 

3. The Data center reply with a Yes or No for every match. If the response is yes then it states that the 
resident is authenticated and vice-versa. 

IRIS based authentication is supported through “kind 7” image formats compliant to ISO 19794-6 standard [ISO 

19794-6, 2011], 

IRIS Authentication Process: 

1. AUA devices using biometric authentication implementing authentication API can benefit from the best 
known methods. 

2. The operator enters the AADHAAR no into the application and captures IRIS image of the resident through 
the IRIS Capture device. 

3. Prompting the resident during IRIS capture - resident and operator benefit from prompting signals 
implemented on device/sensor and helps in achieving high quality IRIS captures. 

o Prompting can be achieved with a sound to signal starting time of capture 

o In case, option to light up sensors exists or providing lights around the sensor is possible, same can 
be considered. 

4. Signaling end of capture to operator is important and helps during multiple captures 

5. The packet containing the IRIS and AADHAAR no. is sent to the CIDR through ASA network for 
authenticating the resident. 

6. The packet data is extracted at CIDR and the AADHAAR no. and the IRIS image is matched with the 
available templates in the data center, capture at the time of enrollment of the resident. 

7. The CIDR response to the operator in just yes or no. 

8. If the set of match is successfully found in the CIDR data then it returns ‘Yes’ to the operator and the 
resident is successfully authenticated. 

9. If the set of data is not successfully matched then it returns with a ‘No’ and it means the resident is not 
authenticated successfully and the operator need to authenticate again following the same procedure or 
need to user other modalities as fingerprint, OTP or demographic details for Authentication. 
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Figure 10: Authentication Process Flow 


He Edt 

rroatae ImOnfcw Mlef Orv» Ini Wman Kefort Uratawet I r *“ I 



Figure 11: IRIS Capture Image 
6.3.8.1.1 OTP Authentication Application 

Authentication focuses on matching a person’s identity based on the reliability of a credential offered. Various 
agencies have different requirements for the degree of assurance required while authenticating residents. 

When using OTP, at a high level, there are two distinct activities: 

1. Application requesting OTP to be sent to resident’s mobile. After the successful API invocation, a newly 
generated random OTP is sent to resident’s mobile. 
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2. Application using the OTP value sends it to UIDAI server for authentication through AUA-ASA network. 

Since OTP usage assumes that the resident is present during the transaction (to be able to provide the OTP value 
received on his/her mobile for subsequent authentication transaction), only a maximum of one OTP is valid for an 
Aadhaar number at any point in time. Every time a new OTP is generated, previous OTP cease to be valid. OTP 
generated has an expiry period for security reasons and it is expected that resident uses the OTP within a 
reasonable time. If not used, OTP expires and a new OTP needs to be generated for next transaction. 

OTP Request Process 

The OTP request work flow is listed below: 

1. An Application, wants to use Aadhaar OTP as a factor within Aadhaar Authentication initiates the 
transaction flow. 

2. Application captures Aadhaar number along with other attributes (name, address, biometric, etc.) as 
needed by the application 

3. Application, through AUA-ASA server, sends the OTP request to UIDAI server. 

4. The UIDAI server processes the input, validates it, generates OTP, and sends it to resident’s registered 
mobile and email (based on Aadhaar data in UIDAI server) 

5. The Residents receives the OTP on his/her mobile and/or email. 

6. The Application then requests the resident to enter the OTP into the application so that application can send 
it for Aadhaar Authentication. 

If OTP has not expired and it matches with the other authentication factors then application responds with a “Yes / 
No” with a return code. 

Note : OTP expires with a UIDAI stipulated time. OTP message sent to resident provides time at which OTP was 
generated and the duration when it is going to expire. Since OTP is always sent to both mobile and email of the 
resident, resident can use the OTP received in his/her mobile/email while authentication. 


Sample Applications UIDAI has developed sample vanilla authentication applications which could be consumed 
by AUAs to integrate with their Aadhaar Applications. Details of the applications are available at 

https://developer.uidai.gov.in/site/downloads 


UIDAI has published API’s which need to be used by Authentication User Agencies (AUA’s) in their application if 
using Aadhaar biometric authentication. 


The API details are available in the URLs mentioned below: 


Sr. 

No. 

Application 

URL Details 

1 

Aadhaar Authentication 

http://uidai.aov.in/imaaes/FrontPaaeUDdates/aadhaar authentication api 1 6.p 

df 

2 

Aadhaar One Time PIN 
(OTP) 

http://uidai.aov.in/imaaes/FrontPaaeUpdates/aadhaar otp reauest api 1 5.pdf 


3 

Aadhaar Best Finger 
Detection (BFD) 

http://uidai.aov.in/imaaes/FrontPaaeUpdates/aadhaar bfd api 1 6.pdf 



Authentication Error Handling 
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It is really important to handle Authentication API errors correctly. Authentication Application should have provisions 
to handle these errors. Details guidelines to handle exception in application are mentioned at below URL: 

https://developer.uidai.gov.in/site/node/39. 

Standards and Specifications 

UIDAI has published Security Policy Specifications and Standards for AUAs and Authentication Devices being 
deployed by AUAs. Some of the mandatory security requirements which every Authentication application should 
adhere to are: 

• PID block captured for Aadhaar authentication should be encrypted during capture and should never be 
sent in the clear over a network. 

• The encrypted PID block should not be stored unless it is for buffered authentication for a UIDAI specified 
period of time. 

• Biometric and OTP data captured for the purposes of Aadhaar authentication should not be stored on any 
permanent storage or database. 

• In the case of operator assisted devices, operators should be authenticated using mechanisms such as 
password, Aadhaar authentication, etc. 

• In case of the OTP Authentication it is mandatory to have beneficiary residents at the point of authentication 
initiated. 

For further details on UIDAI Authentication Standards and Specifications please refer 
http://uidai.qov.in/imaqes/authentication standards and specs vl 7.pdf 


6.4 Compliance 
6.4.1 Audit 

AUAs have to ensure that its operations and systems related to Aadhaar Authentication are audited by information 
systems auditor certified by a recognized body before commencement of its operations and it has to provide a 
certified audit report, to UIDAI, confirming its compliance with the standards, directions, specifications, as specified 
by UIDAI. 

UIDAI recommends following guidelines (which may be revised at the sole discretion of UIDAI) for audit to be 
undertaken by an ASA/AUA. 

List of Documents to be referred for the Audit Purposes 

The documents mentioned below details the standards, policies and specifications for AUAs to follow to ensure 
secure, reliable and continuous Aadhaar authentication services. 


S. No 

Document 

Description 

1 . 

Aadhaar Authentication 

Standards and 

Specifications 

This document provides list of various standards and specifications for 
compliance by an AUA and the link/reference to the respective 
document/resource 

2. 

UIDAI-AUA Aqreement 

Various obligations of the AUA as detailed in the UIDAI-AUA agreement 
signed with UIDAI 
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Audit report submission 

Audit report/ certificate duly signed by auditor and certified by AUA should be submitted to the UIDAI as per 
schedule below: 

a. AUA should submit the report/ certificate to UIDAI prior to the commencement of operations 

b. AUA should submit annual compliance report, upon request by UIDAI, within 30 days of such request by 
UIDAI 

6.4.2 Testing 

AUAs thus have to ensure that its operations and systems work seamlessly with the various components of the 
entire delivery systems. Any disruption in the end to end delivery chain may result in denial of service. Thus it is 
important for the AUAs to test the entire process and the delivery chain end to end, with all the possible 
permutations and combinations. 

So an AUA is required to complete end to end testing for ensuring the developed AUA server and device 
applications connects with ASA application and through ASA to UIDAI database (CIDR). The testing should be 
carried in three stages as listed below: 

1. Testing on UIDAI development testing environment: AUA tests the authentication application by transmitting 
authentication transactions to UIDAI development environment. For details on the development 
environment testing please refer UIDAI Developer at https://developer.uidai.qov.in/site/ . 

2. Testing for ASA connectivity on ASA testing environment: AUA is expected to complete the testing with 
ASA server applications on development environment. AUA is expected to engage an UIDAI approved ASA 
in earlier stages to develop the link between AUA and ASA server which will be used in this stage to 
perform integration testing for successfully transmitting the authentication requests. In certain scenarios, 
depending on the ASA architecture and testing environments an AUA could achieve this only after obtaining 
the AUA pre-production code from UIDAI. 

3. Testing for end to end connectivity on UIDAI pre-production environment: AUA need to request for AUA 
code and license key by sending an email to UIDAI authentication support team at 
authsupport@uidai.gov.in . Once the details are received, AUA would need to get in touch with engaged 
ASA to transmit the transactions to UIDAI pre-production environment. Please note that the request from 
AUA for accessing the pre-production environment will need to go through an internal approval process of 
UIDAI where the team ensures that the AUA has signed the UIDAI-AUA agreement and the AUA has 
entered into an agreement with an UIDAI approved ASA. 

Key areas for testing that an AUA may consider for end to end implementation and testing are: 

The integration of domain application with Aadhaar authentication 

Aadhaar authentication process is just a facilitator for the AUAs and provides authentication services for their 
domain process. It is important that AUA architect the system in way that both the domain process and Aadhaar 
authentication process co-exists and support each other. 

Example: A successful Aadhaar Authentication should facilitate domain process for service delivery and a failed 
authentication process should lead to exception handling in the domain process. 

The transaction between various touch point and process hubs 
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A typical AUA process involves transaction initiated from a device (like MicroATM), going to an AUA server, then to 
an ASA server (for Authentication), then to CIDR and back. 

There are various challenges at each of this transaction points and process hubs. 

Like transaction between the device and the AUA server will contain both Aadhaar authentication info and domain 
specific information. However the connectivity between these two points may have very limited bandwidth. Hence 
there is a challenge to keep the packet size low and ensure that it works on lower possible bandwidth. 

Further the transaction between the AUA and ASA is based on certain requirements like the packet to be signed. 


6.5 Roll out 

6.5.1 Go Live and Training 

6.5.1.1 Go Live 

At this stage an AUA ensures that all the previous stages and their activities are completed to proceed with the Go 
Live checklist for getting access to UIDAI production environment. By this stage an AUA would have sent 
confirmation for compliance to the current standards and specifications as published by UIDAI to get production 
AUA code and license key for creation of the authentication requests. 


Sr No 

Activities 

AUA 

1 

AUA has arranged for infrastructure for digital signature and tested in Pre- 
production environment 

□ 

2 

The Public key corresponding to Digital signature infrastructure submitted to 
UIDAI 

□ 

3 

The format of public key is X.509 

□ 

4 

AUA has conducted end-to-end testing for 100 no of successful transactions in 
Pre-production environment 

□ 

5 

AUA data logging for Authentication Audit trail being provisioned 

□ 

6 

AUA is ready to deploy devices with STQC certified sensor-extractor, if using 
biometric authentication and FDC code(s) have been arranged 

(Refer Aadhaar Authentication API Document, pa 14 & 15) 

□ 

7 

UDC Nomenclature Defined 

□ 

8 

Domain Application is ready for deployment 

□ 

9 

Client Application has provisioned for BFD, two Finger Authentication, UDC, 
Location configuration and Operator login in case of operator assisted devices. 
(Refer Aadhaar Authentication & BFD API) 

□ 

10 

Obtained certificate from an information systems auditor certified by a recognized 
body for compliance to UIDAIs standards and specifications 

□ 

11 

Resident consent process to obtain consent is ready to be deployed 

□ 
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6.5.1.2 Operator Training 

AUAs are required to deliver training modules developed for operators who would be interacting with residents for 
service delivery. The training delivery should focus on the following areas: 

• Usage of biometric devices and Do’s / Don’ts for capturing good quality biometrics. 

• Usage of BFD, process for on-boarding residents and guiding residents for next steps. 

• Exception handling processes (as adopted by the AUA) and ensuring no denial of service to residents due 
to technology limitations. 

• Communicating appropriately with residents. 

• Fraud monitoring and fraud reporting guidelines. 

• Basic troubleshooting steps and contact details of AUA’s device/application support team. 

• Client application (as per the software deployed by the AUA). 

• Process steps (of the AUA) for handling resident requests. 

• Point of Sales /device operations and handling. 

• To avoid duplicate requests. 

UIDAI has developed standard training modules that could be integrated with AUAs business and applications 
training modules. For details of the training modules please refer UIDAI website www.uidai.qov.in/auth or contact 
UIDAI support team. 

6.5.2 Release and Operate 

6.5.2.1 Indicative Deployment View 

Initially AUA can start with providing services using restful web service. These services can be accessed using http 
or https protocol. Figure below depicts possible indicative deployment architecture (assuming clustered 
environment) for such setup. This does not cover in detail communication setup between AUA and ASA as it will 
vary for every AUA and ASA. So link from Application server to ASA is to just for completing the view in real setup 
there may be different component in between AUA application server and ASA. 
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Load 
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DMZ 


Application 

Server/WebServer 


AUA Application 
Instancel 


AUA Application 
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AUA Application 
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Figure 12: Indicative Deployment Architecture 
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Devices/Sub AUAs can access AUA rest web services through http/https protocol. Request can hit on a proxy 
server/load balancer which in turn can forward that request to appropriate instance of AUA application and further 
AUA application can call ASA application and similarly response can be transferred back to end device/Sub AUA. 


7 Suggestions to Improve Authentication Success Rate 

A high success rate is the hallmark of a successful online authentication process. To this day, about 2 Crore 
authentication transactions have been carried out with a success rate of over 92%. Out of the 8% rejects, a major 
chunk is actually true rejects. It is practically seen that if there are no seeding problems or fraud attempts the 
success rate is close to 98% in case of fingerprint and potentially higher with iris. It has also been observed during 
various pilot efforts underway that rejects can be substantially brought down by following laid down procedure and 
in cases where authentication failure persists, performing the diagnostic procedures specified by UIDAI (Best finger 
detection for example for fingerprint authentication) helps in resolving the issues. Rejects can be handled most 
times through laid-down procedures than needing any technical solution. 

Rejects can be further classified into two - True rejects and False rejects. 

7.1 Reasons of True rejects and ways to avoid the same 

A true reject should not be permitted to repeat. The success of the system will largely depend on discerning true 
rejects and prevention of a repeat of rejection of the same Aadhaar number. 


# 

Reasons 

Solutions. 

1 

Seeding problem 

There should be daily Feedback mechanism where the users (AUA) 
should be intimated clearly of the rejected UID numbers, to help 
investigate and eliminate seeding errors. Implementation of Verhoeff 
algorithm in application will largely prevent any clerical error in 
seeding. 

2 

Fraud Attempts - Cases 
where multiple attempts are 
made to authenticate against 
a particular UID. 

Rules and guidelines to prevent Fraud Authentication attempts should 
be promulgated as deterrence. 


7.2 Recommendations 

1. Device: 

• Usage of certified devices is important. 

• Device Nomenclature needs to be implemented. 

• Device Registration process will improve device traceability. 

• Provision to track the location of the device, through Pincode, Geo Tagging etc. is also helpful 

• Provision to track the extractor version of the device needs to be explored 
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2. Client Application: 

• Compliance of the client application as per the backend infrastructure & guidelines issued by UIDAI. 

• Following Standard operating process for fingerprint Authentication 

o Application should mandatorily take the resident's 2 fingers (fusion) at least three times before 
getting into exception handling tracks (offline/manual validation of the genuineness of the resident) 
o Application should have a feature to mandatorily accept quality capture only. I.e. if the quality of the 
capture is bad, application should prompt the resident to try again, do BFD etc. 
o If a compliant finger print authentication (BFD+ Multi finger + Multiple try) fails the application 
should prompt the resident for trying other authentication factors, wherever feasible (OTP for 
example) 

• Following Standard operating process for IRIS Authentication 

o Applications implementing IRIS authentication should follow the process outlined in the IRIS 
authentication proof of concept report. It is recommended that three presentations and three 
attempts till authentication success is achieved is mandatorily implanted in the application, 
o Single eye camera: Each presentation is defined as image of one eye. Second attempt used 
different eye from the first. In other words, the recommended multiple attempt sequence is right 
eye, left eye, right eye and so on. The switching of eyes effectively provides “best finger” strategy 
for two eyes. 

o Dual eye camera: Each presentation is defined as one image of each eye (two iris images). Here 
again, the three attempts should be mandatorily implemented in order to achieve high degree of 
success. Dual eye camera is effectively equivalent to using two fingers for authentication, 
o Application should have a feature to mandatorily accept quality capture only. I.e. if the quality of the 
capture is bad, application should prompt the resident to try again, 
o Application should prompt residents to try other authentication factor after repeated failure using iris 
- examples of other factors include fingerprint, OTP where feasible. 


3. Process & Policies: 

• Audit process and policies for Authentication Client Application to be in place. 

• Guidelines to prevent Fraud Authentication attempts being introduced into the system. 

• Device registration policy to be in place. 


4. Process Compliance: 

• Suggest residents to undergo BFD, perform multi finger authentication, attempt at least 3 times in case of 
authentication rejects. 


5. Authentication Transaction Reporting: 

• Log “Server not available” errors separately as Error transactions and not include in the total 
Authentication Transaction count. This would reduce the inconsistency between the volume projected 
byAUA’s and UIDAI. 


AUA Handbook 


Version 1.0 


Page 39 of 43 




AAPHAAR 


6. Operator Training/Material 

• Training Manual to be developed for operator trainings. 


7. Usage of Poster and Campaigns 

• Posters on Authentication or BFD processes need to be made available in and around the service delivery 
counters/shops. 

• Campaigns are required to create awareness among the residents on the benefits of Aadhaar-based 
service delivery, and the right usage of the applications/devices. 


8 . Verhoeff Algorithm 

• An MS Excel utility containing Verhoeff algorithm (available freely, can be provided) could be used with the 
client application, so that the incorrect UIDs can be captured during seeding. This will reduce error 998 from 
the field. 


7.3 Best Practices 


S. No 

Dimension 

Emerging Best Practices 

1. 

Device Sensor/Extractor 

• Usage of certified Devices/Sensors/ Extractors 

• Operator training for appropriate usage of devices 

• Tracking mechanism for devices being used by AUAs 

• Device should have capability to connect to any type of internet 

sources - USB, LAN Cable, Telephone cable etc 

• Devices should have support for external Antenna in case of 

low connectivity areas. 

2. 

Client Application Compliance 

• Usage of Auth Client applications which are compliant to the 

backend application. 

• Best practices like usage of BFD, 2 finger Auth being catered 

to by the Client Application and Similarly for IRIS 

authentication, use 3 attempts of 3 presentations. 

• Client application should facilitate clarity in the ‘action items’ 

based on the error codes. 

• A unique device code ( UDC )for the authentication device 
assigned within the AUA domain {UDC should be an alpha¬ 
numeric string of maximum length 20). This allows better 
reporting and tracking of the client devices and should be 
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mandatorily used during authentication transaction. The same 
can be used to provide specific feedback regarding the 
device specific behaviours. 

3. 

AUA Operators 

• Operator Trainings being performed. 

• Enhance understanding about Error Codes generated by 

system and corresponding actionable. 

4. 

Enrolment capture Quality 

• Identify errors due to bad biometric capture quality during 

enrolment process, and suggest reenrolment to the residents 

5. 

Two Finger Authentication & BFD 

• Enforce usage of 2 finger authentication, BFD to improve auth 

accuracy. 

6. 

Aadhaar Seeding 

• Ensure that the Aadhaar number seeding is done correctly by 

the AUAs to eliminate seeding errors. 
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8 Appendix 

8.1 Related Publications/Tools 


Sr. No. 

Description 

URL/ Location 

Description 

1 

Aadhaar Authentication 

Strategy Document 

http://uidai.aov.in/imaaes/authDoc/auth strateav ere 

atina a circle of trust.pdf 


2 

Aadhaar Authentication 
Operating Model 

http://uidai.aov.in/imaaes/authDoc/d3 1 operatina m 

odel vl.pdf 


3 

UIDAI-AUA Agreement 
Template 

http://uidai.aov.in/imaaes/FrontPaaeUpdates/d3 6 ui 

dai aua aareement v2 1 .pdf 


4 

AUA Application form 

http://uidai.aov.in/imaaes/aua application form verl 

4. odf 


5 

List of support documents and 
application process 

http://uidai.aov.in/imaaes/FrontPaaeUpdates/asa au 

a application process v2.pdf 


6 

Guidelines for AUA-ASA 
Agreement 

http://uidai.aov.in/imaaes/authDoc/d3 6 auidelines f 

or the aareement between asaaua vl .pdf 


7 

Guidelines for AUA-Sub AUA 
Agreement 

http://uidai.aov.in/imaaes/authDoc/d3 6 auidelines f 

or the aareement between aua asa vl.pdf 


8 

Aadhaar Authentication 
Standards and Specifications 

http://uidai.aov.in/imaaes/FrontPaaeUpdates/authenti 

cation standards and specs vl 7.pdf 


9 

Illustrative Template of 

Resident Consent Form for 

Aadhaar Authentication 

http://uidai.gov.in/images/FrontPageUpdates/resident 
_consent_form_for_aadhaar_authenticationJllustrati 
ve template v1 0.pdf 


10 

UIDAI Empanelled 

Consultants 

http://uidai.aov.in/imaaes/FrontPaaeUpdates/final e 

mpanelment list 30 mav 2011.pdf 


11 

Aadhaar Developer Portal 

http://developer.uidai.aov.in/site/ 

Provides client 
software, APIs, 
Authentication 
Sample 

application and 
Technical 

papers 
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12 

Aadhaar Authentication 
Discussion Group 

httDs://arouDs.aooale.com/forum/#iforum/aadhaaraut 

h 

Group to 

encourage 

collaboration 

between 
development 
community by 
facilitating 
Aadhaar 

Authentication 

related 

technical and 

integration 

discussions 

13 

UIDAI Authentication 

Application Developer Portal 

https://developer.uidai.aov.in/site/auth basics 


14 

Authentication API 

http://uidai.aov.in/imaaes/FrontPaaeUpdates/aadhaar 

authentication aoi 1 6.odf 


15 

Best Finger Detection API 

http://uidai.aov.in/imaaes/FrontPaaeUDdates/aadhaar 

bfd aoi 1 6.pdf 


16 

Technology FAQs 

http://developer.uidai.aov.in/site/auth tech faas 


17 

Demographic Data Standards 

http://uidai.aov.in/UID PDF/Committees/UID DDSV 

P Committee Report vl .O.pdf 



8.2 Glossary of Terms and abbreviations 


Sr. No. 

Term/ 

Abbreviation 

Description 

1 

API 

Application Program Interface 

2 

ASA 

Authentication Service Agency 

3 

AUA 

Authentication User Agency 

4 

BFD 

Best Finger Detection 

5 

CIDR 

Central Identities Data Repository 

6 

STQC 

Standardization Testing and Quality Certification 

7 

UIDAI 

Unigue Identification Authority of India 

8 

IRIS 

Image Recognition Integrated Systems 

9 

OTP 

One Time Pin 
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